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Abstract 

An  automated  computer  time  distribution  system  broadcasts  standard  time  to  users  using  computers 
and  modems  via  telephone  lines.  For  users  who  need  traceable  time,  it  is  of  particular  interest  to 
know  the  uncertainty  of  time  information  received  Factors  that  contribute  to  transmission  delays  in 
a  telephone  network  have  been  measured  and  analyzed  The  results  revealed  several  dominant 
factors  that  contributed  to  delays  -  software  platform  (50%  of  the  delay),  transmission  speed  of  time- 
codes  (25%),  telephone  network  (15%),  modem  and  others  (10%).  The  standard  deviation  of  delays 
is  below  20  ms  in  all  cases.  The  results  allow  us  to  estimate  that,  within  Singapore,  an  uncertainty  of 
about  20  milliseconds  is  achievable  using  the  system. 

INTRODUCTION 

A  service  that  distributes  time  -  the  Automated  Computer  Time  Service  (ACTS)  -  has  been  set  up  at  the 
National  Measurement  Center  (NMC)  of  Singapore  Productivity  and  Standards  Board  (PSB).  The  system 
broadcasts  standard  time  to  users  via  computers,  modems,  and  telephone  lines.  Users  dial  the  ACTS 
server  to  receive  time  traceable  to  the  national  time  scale  of  Singapore,  UTC(PSB).  The  users  can  in  turn 
run  applications  that  require  traceable  timekeeping,  such  as  traffic  controls,  communications, 
synchronized  clocks,  etc. 

The  ACTS  system  transmits  time  code  in  ASCII  format.  To  remove  errors  due  to  delays  in  transmitting 
codes,  the  ACTS  server  has  the  capability  to  compute  and  compensate  each  transmission  delay  by  first 
measuring  the  round  trip  delay.  It  then  corrects  for  one-way  delay  through  time  code  advancement.  PSB 
provides  dial-up  software  on  both  Windows  and  DOS  platforms  to  users.  This  software  echoes  an  On- 
Time  Marker  (OTM),  which  enables  the  server  to  compute  and  compensate  delays.  Time  code 
transmitted  by  this  service  is  compatible  with  that  of  a  similar  service  provided  by  the  National  Institute 
of  Standards  and  Technology  (NIST)  [1], 

For  users  who  need  traceable  time,  it  is  important  to  know  the  uncertainty  of  time  code  received,  which  is 
caused  by  delays  when  the  code  travels  through  various  media  along  the  transmission  path.  A  detailed 
analysis  of  these  delays  enables  service  providers  such  as  PSB  to  assign  an  uncertainty  to  the  time  code 
received  by  the  users. 

FACTORS  CONTRIBUTING  TO  DELAYS 

In  the  transmitted  time  code,  there  is  an  On-Time  Marker  (OTM)  denoted  by  an  asterisk  (*).  OTM  serves 
as  a  reference  point  for  the  time  code  -  time  indicated  by  the  code  refers  to  the  arrival  time  of  OTM.  For 
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example,  if  the  time  code  shows  12:34:56,  it  means  that  the  time  is  12:34:56  at  the  arrival  of  OTM. 

The  OTM  is  delayed  in  the  transmission  path  as  it  travels  from  the  server  to  the  user’s  computer.  To 
compensate  for  this  delay,  the  ACTS  server  sends  out  the  OTM  a  fixed  number  of  milliseconds  early. 
This  helps  to  improve  the  accuracy.  Better  results  are  possible  if  the  users  return  the  OTM  to  the  server. 
On  receiving  the  returned  OTM,  the  server  measures  the  time  it  took  for  the  OTM  to  travel  from  server  to 
the  user  and  back.  It  then  divides  the  measured  round-trip  delay  by  2  to  get  the  one-way  path  delay.  This 
of  course  assumes  reciprocity  in  the  path.  ACTS  server  then  advances  the  OTM  by  die  calculated  one¬ 
way  path  delay  and  sends  out  the  code.  If  the  OTM  changes  from  an  asterisk  to  a  hex  sign  (#),  the  server 
is  measuring  the  delay  and  correcting  for  it.  On  receiving  the  #  sign,  the  user  knows  that  error  due  to  path 
delays  has  been  removed,  and  the  time  received  is  within  a  few  milliseconds  of  UTC(PSB).  The 
remaining  error  is  due  to  the  transmission  asymmetry  and  noises. 

Figure  1  shows  the  system  used  for  measuring  delays.  During  the  boot-up  of  the  ACTS  server,  we  used  a 
RS232  signal  from  a  Time  Code  Generator  (TRAK  model  6460),  which  is  synchronized  to  UTC(PSB),  to 
automatically  set  the  server  time.  The  system  then  is  operated  continuously  from  a  lpps  signal  of 
UTC(PSB).  Three  main  elements  contribute  to  delays  in  such  setups  -  modems,  telephone  lines,  and 
computers.  Furthermore,  the  amount  of  delay  also  depends  on  the  type  of  modem  and  its  speed,  the 
location  of  users,  the  type  of  computer  used,  software  platforms,  etc.  Delay  may  also  vary  depending 
on  the  time  of  day  at  which  transmission  takes  place. 

METHOD  OF  MEASUREMENTS 

Each  of  the  delay  factors  mentioned  above  were  investigated  individually,  while  keeping  the  other 
influencing  factors  unchanged  as  much  as  feasible.  For  example,  to  measure  delays  of  various  modems, 
all  connections  remained  unchanged  and  dialing  was  done  for  the  same  time.  To  measure  variations  in 
delay  over  time,  we  kept  the  same  computer  and  modems.  Measurements  were  carried  out,  at  the  same 
location,  for  51  days  from  51330  to  51380  MJD.  Server  was  dialed  daily  in  three  blocks  -  morning 
afternoon,  and  evening.  Each  block  consisted  of  10  dial-ups,  and  each  dial-up  involved  tens  of  delay 
measurements  and  stability  calculations.  Only  the  one  that  satisfied  stability  criteria  of  several  ms  was 
recorded.  Sometimes,  the  conditions  were  not  identical,  but  all  data  and  conditions  were  made 
comparable. 

The  total  data  we  collected  for  the  testing  are  over  12p00  pieces.  One  piece  of  data  records  the 
advancement  or  the  delay  of  OTM,  either  the  #  or  *  sign,  and  the  difference  between  the  user’s  computer 
time  and  standard  time. 

MEASURED  RESULTS  AND  DISCUSSIONS 

In  Figure  2,  delays  of  several  modems  were  averaged  in  three  blocks  daily.  Time  code  transmission 
speed  was  set  to  9600  baud.  Data  were  collected  from  51330  to  51380  MJD.  Dial-up  software  operated 
on  Windows  platform.  Figure  2(a)  shows  the  means  and  standard  deviations  of  4  modems  in  the  morning 
block  (at -around  1000  hours).  Figure  2(b)  shows  the  results  of  the  same  4  modems  in  afternoon  block 
(around  1500  hours).  Figure  2(c)  is  the  results  of  the  evening  block  (around  2200  hours),  in  which  the 
first  two  modems  are  the  same  as  that  used  in  the  morning  and  afternoon  blocks.  All  blocks  used  similar 
computers.  Other  conditions  are  about  the  same  during  the  three  blocks  of  measurements.  Figures  2(a), 
(b),  and  (c)  show  that  delays  did  not  differ  significantly  among  the  three  blocks.  Delay  of  the  first  two 
modems  -  US  Robotic  33. 6K  and  Prolink  14.4K  -  was  around  145  and  125  ms,  respectively  for  morning, 
afternoon, and  evening  blocks.  Standard  deviations  were  around  15  ms.  Capacity  of  modems,  however, 
has  slight  influence  on  the  delay.  For  example,  the  14.4K  modem  was  around  125  ms.  It  went  up  to  140, 
145,  and  150  ms  for,  respectively,  28. 8K,  33.6K,and  56. 6K  modems.  In  all  cases,  stability  of  delays,  or 
standard  deviation,  stays  almost  the  same  at  about  15ms. 
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Figure  3  shows  the  diurnal  effect  on  the  delay.  Measured  data  came  from  the  same  modem,  with 
Windows  software  ran  at  a  speed  of  9600  baud,  and  DOS  software  ran  at  a  speed  of  1200  baud.  The 
client  computer  dialed  the  server  10  times  each  hour  around  the  clock  continuously  from  51459  to  51461 
MJD.  It  shows  that  delays  fluctuate  between  135  ms  and  155  ms  for  Windows  software,  and  around  108 
ms  for  DOS  software.  The  standard  deviations  were  around  15  ms  and  5  ms,  respectively.  It  is  apparent 
that  software  platforms  contributed  considerable  delays  to  transmission,  while  the  delays  remain  largely 
the  same  throughout  the  day. 

Figure  4  compares  the  delays  of  two  client  computers  -  486-66MHz  and  Pentium  II-233MHz.  486  ran  on 
DOS  platform,  while  Pentium  II  ran  on  both  Windows  and  DOS  platforms.  Each  setup  was  tested  at  two 
speeds  -  1200  and  9600  baud.  Results  show  hardly  any  difference  in  delay  between  two  different  client 
computers.  For  example,  the  delay  was  around  55  ms  for  both  computers  when  dialing  on  DOS  at  a 
speed  of  9600  baud,  and  around  108  ms  when  dialing  on  DOS  at  a  speed  of  1200  baud.  When  the  same 
computer  (Pentium  II)  operated  on  Windows  and  DOS  platforms,  the  delays  differed  significantly.  At 
9600  baud,  delays  when  operated  on  Windows  and  DOS  were  around  150  ms  and  55  ms,  respectively.  At 
1200  baud,  the  figures  for  Windows  and  DOS  were  around  190  ms  and  108  ms,  respectively.  Standard 
deviations  of  DOS  system  were  around  5  ms,  while  that  of  Windows  were  between  10  and  20  ms. 
Therefore,  dialing  with  DOS  software  produces  smaller,  and  also  more  stable,  delays. 

Next,  we  investigated  different  modems.  Figure  5  shows  delays  obtained  by  different  56. 6K  modems 
(commonly  found  in  the  current  market)  at  1200  and  9600  baud,  dialed  on  DOS  and  Windows  platforms. 
It  shows  that  at  9600  baud,  all  modems  had  similar  delay,  and  that  was  true  on  both  DOS  (around  50  ms) 
and  Windows  platforms  (around  150  ms)  .  The  differences  between  modems  did  not  exceed  10  ms.  At 
1200  baud,  however,  the  measured  delays  spread  from  70  ms  to  200  ms.  DOS  software  at  9600  baud 
seems  to  offer  the  best  solution  to  users  who  need  an  uncertainty  of  a  few  milliseconds. 

The  last  test  involved  dialing  the  server  from  various  parts  of  Singapore.  Figure  6  gives  the  locations  of 
client  computer,  while  Figure  7  show's  the  measured  delays.  There  was  no  noticeable  correlation  between 
measured  delays  and  dialing  locations.  Telephone  connections  in  Singapore  are  randomly  distributed, 
and  each  connection  does  not  exceed  three  exchanges  island  wide  (around  680  square  meters).  Assuming 
the  worst  delay  of  10  ms  at  one  exchange,  the  total  delay  caused  by  the  telephone  network  would  be  30 
ms  at  most. 

CONCLUSION 

The  dominant  factor  contributing  to  delays  is  the  software  platform,  which  makes  up  about  50%  of  the 
total.  Dial-up  software  on  DOS  has  smaller  delay  and  is  more  stable.  Speed  of  transmission  contributes 
about  25%  of  delays,  and  9600  baud  offers  the  best  connection.  About  15%  could  be  caused  by  the 
telephone  network.  Modems  may  put  in  another  5%  of  delay,  depending  on  the  type  and  capacity,  with 
the  rest  comes  from  unknown  factors  such  as  noise.  The  smallest  delay  of  50ms  is  achievable  with  the 
system  running  on  DOS  platform  at  9600  baud.  The  largest  delay  is  about  200ms  on  Windows  platform 
at  1200  baud.  Standard  deviations  for  operating  under  DOS  and  Windows  platform  are  5  and  20  ms 
respectively.  These  standard  deviations  are  an  estimate  of  the  uncertainty  of  the  system  after  correcting 
for  the  delays. 
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Figure  2(a)  morning  block 
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Delay  and  standard  deviation  (ms)  Delay  and  standard  deviation  (ms) 
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Figure  2(b)  afternoon  block 
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Figure  2.  Long-term  variations  in  transmission  delays 
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Figure  3.  Diurnal  variations  in  transmission  delays 
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Figure  6.  Locations  of  client  computers 


Figure  5.  Transmission  delays  due  to 
different  modems  and  speeds 
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